Why

This PR addresses the following problem / context:

• The contact and phone schema should not accommodate invalid legacy data (mostly phone numbers)
• We need a way to persist that invalid legacy phone data so it's still usable by AMMP colleagues when needed
• Second contacts from OwnersData should not be added if all Second fields are null

How

Implementation summary - the following was changed / added / removed:

• Added new IncompleteNMAPhone model to store that data
• Made Phone.phone non-nullable
• Skip trying to add a second contact if any of SecondFirstName, SecondLastName, SecodnCtctEmail, or SecondCtctPhone are null

Notes

Any special considerations, workarounds, or follow-up work to note?

• Instead of storing the invalid (incomplete) phone numbers in the contact model I decided to put them in a separate class. This way the contact model won't be compromised and amended for invalid legacy data. We can still easily display that invalid data, and if/when we decide to no longer display that data we can remove it from ContactResponse
• @ksmuczynski and I thought that IncompleteNMAPhone best describes the data. It is invalid in terms of Pydantic validations, but they still work (if an area code can be determined). We thought this would best communicate the state of the data to users
  • If we want to to set a naming standard for "invalid" or "incomplete` legacy data that we want to preserve (for now), should we come up with a naming convention? Is this good enough?
• An aside: I changed the names of the metric and transfer logs to make them look less cluttered and easier to read at a glance. ":" can't be in a file name (at least on Windows), which is what instigated this update.)
• When someone queries GET /contact/{contact_id}/phone should the invalid legacy records be returned too? I'm leaning toward no because they are in a separate table, but could see an argument for their inclusion